On the Internet, when a client requests a web-page from a network device, typically a web-server or a web accelerator, the conventional procedure follows several general steps. First, the client device requests a web-page object, typically in the form of a marked-up document, from the network device. Next, after the client receives the document from the network device, the client compiles the document. Within the document are contained “links” which are specified requests for objects necessary to compile the document into the web-page as seen on the client device.
As the client complies the document, the links are processed one by one until all the requested objects are delivered to the client and the web-page is completed. The links contain uniform resource locators (URLs) that indicate network paths to the embedded objects. A portion of the URLs includes a shorthand address corresponding to the network devices according to a domain name system (DNS). That shorthand address is typically called a “domain name”. When the client is compiles the web-document, the domain names in the links must first be translated by a DNS server into IP addresses representing the actual network location of the network devices that possess the embedded objects.
Conventional procedures, however, suffer from particular drawbacks. For instance, typically, the marked-up document is generally written long before the client requests the document. As a result, the embedded links can only contain information that will be reliable in the future. Typically, that kind of information usually consists only of the domain name and the name of the embedded object. As a result, when the links are compiled, the DNS server cannot take into consideration current information about the client, or the network, in serving the embedded objects.
For instance, the conventional procedure does not take into account various network conditions during DNS translation. For example, two separate network devices may contain a particular object as requested in a particular link. One of the network devices may be particulary bogged down with requests while the other network device is relatively free of requests. When the DNS server translates the domain name to an IP address, however, the DNS server is not aware of the condition of the two network devices on the network. Consequently, the DNS server may blindly translate a domain name, in one of the links, into an IP address corresponding to the bogged down network device.
In addition, the conventional procedure does not take into account the information about client during DNS translation. For instance, on a network, two network devices may contain a particular object, but one network device is very distant from the client while the other network device is very close. During DNS translation, however, the DNS server is unaware of the client's location and, consequently, may blindly translate the domain name into the IP address for the network device that is very distant.
Therefore, a need exists for a method of solving the problems found in conventional procedures.